Skip to content

fix(media-use): ingest derived video outputs#2310

Merged
miguel-heygen merged 4 commits into
mainfrom
fix/media-ingest-video
Jul 13, 2026
Merged

fix(media-use): ingest derived video outputs#2310
miguel-heygen merged 4 commits into
mainfrom
fix/media-ingest-video

Conversation

@miguel-heygen

Copy link
Copy Markdown
Collaborator

What

  • allow video as an ingest-only resolve --from media type
  • default extensionless video ingests to .mp4
  • add an end-to-end resolve regression that verifies the manifest and .media/video path

Why

references/operations.md documents resolve --from talk.cut.mp4 --type video, and the manifest already owns a video subdirectory, but the CLI rejected video because provider-backed resolve types and ingest types shared one validation list.

Reproduction

Confirmed on 0.7.55: resolve --from derived.mp4 --type video exits 2 and lists types without video.

Verification

  • resolve engine: 31 passed
  • manifest/cache: 24 passed
  • registry: 14 passed
  • formatting and git diff --check pass

@james-russo-rames-d-jusso james-russo-rames-d-jusso left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed at 0ee302e5.

Small, correct unblock. The provider-backed types (listTypes()) legitimately shouldn't include video (there's no provider that "resolves" a video from a prompt/entity — you always bring your own file), but ingest-only shape via --from is exactly the right escape hatch, and the manifest already owned the .media/video/ subdir + nextId sequence so no downstream plumbing needed. .mp4 default is a sensible bias for the extensionless-source case (uncommon but real for pipelines that emit derived outputs without keeping extensions).

Verified REGISTRY in registry.mjs is a static object literal populated at parse time (not via side-effect imports), so listTypes() returns stable keys regardless of when it's called — the const INGEST_TYPES = [...listTypes(), "video"] computation is safe. And ES module import hoisting means all imports (including those after line 23) resolve before the const declaration executes.

The sibling unknown type error lists grade and lut test at resolve.test.mjs:388 isn't affected because it uses --type bogus without --from — different code path, different error message.

Nits

  • 🟡 const INGEST_TYPES = ... at resolve.mjs:23 is placed between import statements (after cube-validate at 21, before grade-analyzer at 24). Correct under ES module hoisting semantics but stylistically unusual — a reader unfamiliar with the hoisting rules could reasonably suspect a stale-listTypes() bug (I initially did). Moving the const below the entire import block would keep the "all imports first, then executable code" convention that most codebases (and eslint-plugin-import/first) enforce, at no correctness cost.

LGTM.

Review by Rames D Jusso

@miguel-heygen

Copy link
Copy Markdown
Collaborator Author

move INGEST_TYPES below the complete import block

Addressed in 1b627e231: all imports now precede executable initialization, and the skills manifest was regenerated. Evidence: resolve harness 31/31; generated manifest check; targeted format check.

@james-russo-rames-d-jusso james-russo-rames-d-jusso left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

R2 reviewed at 1b627e23, delta from R1 head 0ee302e5.

R1 style nit addressed — INGEST_TYPES = [...listTypes(), "video"] now sits AFTER the import block at resolve.mjs:38 instead of between imports. Manifest hash regenerated. Behaviorally identical (ES module import hoisting made the prior placement functionally correct), just conventional now.

LGTM from my side.

Review by Rames D Jusso

@jrusso1020 jrusso1020 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving on Rames-D's go (R2 delta clean, nit round addressed) + Magi's CI-green confirmation. Verified at final head 1b627e23: CI green, no changes-requested, mergeable.

@james-russo-rames-d-jusso james-russo-rames-d-jusso left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

R3 reviewed at c17bc357, post-merge with main. Delta from R2 head 1b627e23.

Merge-conflict resolution touches only the generated skills-manifest.json hash for media-use — regenerated to 14d15dedf7acd4ed after main's own media-use changes (#2257) landed. The substantive resolve.mjs diff (INGEST_TYPES const below imports + !INGEST_TYPES.includes(type) gate in ingest + DEFAULT_EXT.video = ".mp4" + regression test) is byte-identical to R2.

LGTM from my side.

Review by Rames D Jusso

@jrusso1020 jrusso1020 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-approving on Rames-D's R3 go. Post-merge head c17bc357 is byte-identical to R2 except the regenerated skills-manifest.json hash; CI green, no changes-requested.

@miguel-heygen miguel-heygen merged commit 7c0dcb0 into main Jul 13, 2026
40 checks passed
@miguel-heygen miguel-heygen deleted the fix/media-ingest-video branch July 13, 2026 02:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants